This could get annoying to update every year - to me the copyright is just the year it was created, so actually the older the better (showing stability/maturity of package)

@bendichter What do you think?

As far as looking stale, I think the commit history tells the story. I'd rather not modify the dates to be a range. While a single date can indicate the start, if we use a range then the package really will be out of date on Jan 1 2025

nobody looks at commit history while going through documentation

looking at documentation and seeing 2022 doesn't tell me that the project is that old, it tells me that it is possibly no longer developed . I will not jump to github to verify etc.

It is very easy to update once a year

I had similar discussions for dandi-archive I believe.

But of cause it is just my 1c, the tool is yours... but forgetful me might suggest the same later ;-)

It looks like many popular libraries do indeed specify a range and update it yearly

https://github.com/NeurodataWithoutBorders/pynwb/blob/dev/Legal.txt

https://github.com/numpy/numpy/blob/main/LICENSE.txt

https://github.com/pandas-dev/pandas/blob/main/LICENSE

Thoughts @stephprince ?

I am good with updating the dates to be a range. In pynwb it's part of the release template checklist to update the dates which is helpful. I don't think there's a similar checklist here, but I think for a once-a-year update that's fine to remember.

@CodyCBakerPhD how more could I be of help? ;)

@yarikoptic Steph is willing to take care of this so it is in their hands now. Likely hear back from them in next 48 hours